In the global economy of today, multi-state and multinational companies are commonplace. For such businesses to work effectively, secured intracompany communication channels are of significant importance. Until recently, leased lines ranging from Integrated Services Digital Network (ISDN) to OC3 (Optical Carrier-3) fiber have been employed. The Internet has provided the framework for a new, less expensive intracompany communication modality known as the Virtual Private Network (VPN).
A VPN is essentially a private network that uses a public network (e.g., the Internet) to connect remote sites or users together. Unlike leased lines that use a dedicated connection, the VPN uses “virtual” connections routed or tunneled through the Internet from a company's private network or central site to the remote site of the employee. A “tunnel” is an intermediary program, which is acting as a blind relay between two connections. The tunnel can be formed as defined by any number of protocols, including the Internet Security Protocol (IPsec), the Point-to-Point Tunneling Protocol or PPTP, and the Layer 2 Tunneling Protocol (L2TP).
There are two primary types of encrypted VPNs extended to teleworkers, namely IPsec VPNs and Secure Sockets Layer/Transport Layer Security (SSL/TLS) VPNs. IPsec VPNs connect between a corporate server and a dedicated hardware or software client. Such VPNs support TCP or UDP traffic and can be extended to support other traffic types through the use of GRE (Generic Routing Encapsulation). SSL VPNs allow clients to use general purpose web browsers to connect to an enterprise's VPN server. They are more limited in functionality than IPsec VPNs, because they support only TCP traffic.
The process to effect a typical VPN session will be discussed with reference to FIG. 1. The central site 100 includes a firewall 104, main office LAN 108, and VPN server 112 (such as IPsec or SSL VPN server). The remote site 116 includes a firewall 120, VPN client 124, and remote office LAN 128. The two LANs 108 and 128 are interconnected by an untrusted network 132 (such as the Internet).
Although the VPN server 112 is depicted as being separately connected to the main office LAN 108, the VPN server 112 may also reside between the main office LAN 108 and the firewall 104. Alternatively, the VPN server 112 may be integrated to the firewall 104.
Tunneling is used by the VPN client 124 and server 112 to effect secured communications between a remote communication device and the central site. Tunneling places the entire packet within another packet and sends the encapsulated packets over the untrusted network 132. Tunneling requires three different protocols, namely a carrier protocol dictated by the untrusted network (e.g., IP), an encapsulating protocol (such as Generic Routing Encapsulation or GRE, IP Security Protocol or IPsec, Layer 2 Forwarding or L2F protocol, Point-to-Point Tunneling Protocol or PPTP, Layer 2 Tunneling Protocol or L2TP, Secure Socket Layer (SSL), Transport Layer Security TLS, Layer 3, and the like), and a passenger protocol dictated by the original data (IPX, NetBeui, IP, and Voice over IP or VoIP protocol(s)) being carried. For example, in IPsec an IP packet is encrypted and encapsulated inside another IP header.
Creation of a VPN helps to establish a secured communication channel between the secure main office LAN 108 and a remote office LAN 116. One downside to current VPNs is that they rely upon a VPN server 112 to facilitate secured communications. Accordingly, communications processing capabilities such as bandwidth are determined and limited by the capabilities of the VPN server 112. Peer-to-peer (P2P) networks on the other hand rely primarily on the computer power and bandwidth of participants in the network rather than concentrating it in a relatively low number of servers. P2P networks are useful in instances where users wish to share files and other real-time and non-real-time data or communications.
Examples of current Internet based P2P networks include Skype, Nimeat, Yahoo Instant Messenger and the like. Such P2P networks are relatively straightforward direct-connected networks, discounting that some need an arbitrating server like STUN, ICE, TURN and so on for resolving connectivity when a caller and/or callee operates behind Network Address Translation (NAT) devices or rely on Internet-based non-NATed intermediaries. Such P2P networks do not rely on an overlay topology to operate. Rather, most P2P networks are like any two entities communicating with one another in a communication network. Moreover, any grouping of P2P participants is not currently driven by client rules. Rather, groupings of P2P participants are traditionally based on a rules-based grouping or community as facilitated by central servers for presence and other policies. This takes control of the P2P network away from the client. In other words, current P2P networks are not currently completely autonomous from the rest of the network, although such, networks can distribute processing tasks.
There have been suggestions to combine VPNs with P2P networks. For example, in an IEEE paper by Aoyagi et al, entitled “ELA: A Fully Distributed VPN System over Peer-to-Peer Network”, the entire contents of which are hereby incorporated, herein by this reference, a fully distributed VPN system over a P2P network is proposed. The fully distributed VPN system over the P2P network is referred to therein as an Everywhere Local Area (ELA) network. The ELA network allows the establishment of a private overlay network for a VPN among nodes of a group without any servers. This allows the VPN system to build up without tire user of a VPN server, thereby alleviating the processing bottleneck and single point of failure inherent to the VPN server. Although this particular paper helps distribute the processing problems inherent with conventional VPNs, the paper does not address the problems associated with P2P networks, which are traditionally not standalone or autonomous.